
-------- TML Message #722 --------

Archive-Message-Number: 722
Date: Fri, 17 Nov 89 14:28:11 EST
From: ("William B. Morrison") morrison@pyr.gatech.edu


Date: Fri, 17 Nov 89 10:25:29 EST
From: Bill Morrison (Coordinator) <morrison@pyr.gatech.edu>
Reply-To: Traveller System Generation Group@pyr.gatech.edu
Subject: Traveller System Generation Group Digest V1 #3
To: traveller@dadla.wr.tek.com


Traveller System Generation Fri, 17 Nov 89       Volume 1 : Issue   3 

Today's Topics:
                            Administratia
         Another (should be) hot topic: data formats (3 msgs)
                           Background? Me??
                           Background Info
                             Black Holes
                          Compilers (2 msgs)
         Discussion group membership and programming workload
                            Here it is...
                            Here we go.,..
            Information to make available (maybe in maps)
                             More ideas.
                      Planet generators (2 msgs)
                      Representation of Spheres
                             Star Systems
                            traveller maps
                  TRAVELLER Star System Data Formats
                Traveller Star System Generation Group
                      Where to send the surveys


***************************************************************************
** STAR SYSTEM DIGEST: star system generation, storage, and display.     **
** All followups on this topic should be sent to morrison@pyr.gatech.edu **
** They will be edited for clarity and resent to the Traveller Mailing.  **
***************************************************************************

- ----------------------------------------------------------------------

Date: Mon, 6 Nov 89 09:21:21 EST
From: morrison%pyr@gatech.edu (William B. Morrison)
Subject: Administratia
To: METLAY@vms.cis.pitt.edu, burdick@hpindl1.hp.com, dan@engrg.uwo.ca,

First, Dan Corrin and I have come up with a questionnaire that we would
like everyone to fill out and return to Dan. This questionnaire is
intended to get a sampling of the various randes of expertise in
the discussion group, and to get a gist of what everyone would like
to see in the first build of our system, intermediate builds,
and the finished product. We would appreciate you getting it back to 
Dan <dan@engrg.uwo.ca> at your earliest convenience.

- --Bill

- ------------------------------

Date: Tue, 31 Oct 89 09:13:56 EST
From: morrison%pyr@gatech.edu (William B. Morrison)
Subject: Another (should be) hot topic: data formats
To: METLAY@vms.cis.pitt.edu, burdick@hpindl1.hp.com, dan@engrg.uwo.ca,

Here's something that we've hinted at but haven't discussed: how are
we going to store input, transient, and output data? Now I know that
according to standard software engineering techniques we don't need to
define this for a while yet, it could influence our design if we specify
all data to be stored in ASCII format, for example.

I think that it should be required that we store all data in ASCII format. 
This will allow the referee generating the systems to massage the data
in any way deemed necessary to get the desired results. They just pull
the data file into their favorite editor and in a few minutes, they are
ready to go. However, this dramatically increases the amount of data
validation we must do since we can't guarantee data integrity anymore.

For my information, what data formats have been used to store data
in existing programs? I would guess that most programs would use
binary (flags, numbers, enumerated types, etc) and records. Both of
which would be hard to edit with a debugger and just about
impossible with anything else. I would also hazard a guess that a
majority of our end users will use this/these programs on PCs,
Macs, etc.

Now for the standard questions: what do you think? What is a better
way of doing it that will still allow users to edit data files by
hand? Do we even *want* users to edit [transient] data files?

By 'transient' I mean both data files that exist only during the
operation of the system *and* those data files used between
modules (eg. output from one module is used as input to another).

- --Bill

PS- I thought of a 'edit data files' program, but we don't know all
    of the data files we'll need yet, and ASCII data files nicely
    side-steps the problem of having a potentially huge and
    intelligent data file editor.

- ------------------------------

Date: Tue, 31 Oct 89 10:12:34 EST
From: Dan Corrin <dan@engrg.uwo.ca>
Subject: Another (should be) hot topic: data formats
To: JEDI@drycas.club.cc.cmu.edu, METLAY@vms.cis.pitt.edu,

<Bill>
> Here's something that we've hinted at but haven't discussed: how are
> we going to store input, transient, and output data? ...

There are really only two choices I can think of, ASCII and binary. There
are advantages and disadvantages to each.
ASCII is easy to read, store, and can be modified easily.
it is also bulky, and data verification code will have to be added to 
each module.
Binary is compact, has better data integrity, and requires less code.
it is difficult to change (ie. requires a special editor), highly
susceptible to data damage, and difficult to read.

The real trade off is space vs. difficulty to access. ASCII takes more
space (both code and data storage), and binary is difficult to use.

> 
> Now for the standard questions: what do you think? What is a better
> way of doing it that will still allow users to edit data files by
> hand? Do we even *want* users to edit [transient] data files?
> 
> By 'transient' I mean both data files that exist only during the
> operation of the system *and* those data files used between
> modules (eg. output from one module is used as input to another).
> 

I believe that data files used between modules (which we haven't actually
decided on using), should be the same format as the input and output files,
as that is essentially what they are. The temporary files (if any), should
be left up to the programmer, I can't think of any reason (at this time),
why people would need access to them, come to think of it I can't think of
any reason to use them at all.

	That's my opinion.
			-Dan

- ------------------------------

Date: Tue, 31 Oct 89 9:46:55 EST
From: 45252-Peter L. Berghold <hplabs!allegra!violin!plb@gatech.edu>
Subject: Another (should be) hot topic: data formats
To: allegra!pyr.gatech.edu!morrison  (Traveller Programmer's Sig)

>> 
>> I think that it should be required that we store all data in ASCII format. 
>> This will allow the referee generating the systems to massage the data
>> in any way deemed necessary to get the desired results. They just pull
>> the data file into their favorite editor and in a few minutes, they are
>> ready to go. However, this dramatically increases the amount of data
>> validation we must do since we can't guarantee data integrity anymore.
>> 
ARRRRRGHHHH!!!!!

>> For my information, what data formats have been used to store data
>> in existing programs? I would guess that most programs would use
>> binary (flags, numbers, enumerated types, etc) and records. Both of
>> which would be hard to edit with a debugger and just about
>> impossible with anything else. I would also hazard a guess that a
>> majority of our end users will use this/these programs on PCs,
>> Macs, etc.
>> 
I would be more in favor of this type of methodology PROVIDED THAT THE 
DATA TYPES AND STRUCTURES ARE THOROUGHLY DOCUMENTED.  Also, great care 
must be taken to ensure backward compatibility in the event that future 
revs cause these structures to change.  (Some type of header info that 
tells which rev the records were written with.)

>> Now for the standard questions: what do you think? What is a better
>> way of doing it that will still allow users to edit data files by
>> hand? Do we even *want* users to edit [transient] data files?
>> 
>> By 'transient' I mean both data files that exist only during the
>> operation of the system *and* those data files used between
>> modules (eg. output from one module is used as input to another).
>> 
>> PS- I thought of a 'edit data files' program, but we don't know all
>>     of the data files we'll need yet, and ASCII data files nicely
>>     side-steps the problem of having a potentially huge and
>>     intelligent data file editor.
>> 

A data files editor doesn't need to be huge.   In fact if modularity is 
maintained, the editor could be built up from the same routines that 
write and read the data from the "main" programs.

Pete

- ------------------------------

Date: Fri, 20 Oct 89 9:15:14 EDT
From: 45252-Peter L. Berghold <hplabs!allegra!violin!plb@gatech.edu>
Subject: Background? Me??
To: allegra!pyr.gatech.edu!morrison  (Traveller Programmer's Sig)

My turn.   As my .signature shows I am a System Administrator for AT&T.  Unlike
some of you other folks, I don't hold any degrees.   I learned my programming
from the school of hard knocks.   I have been involved in computers and 
computer programming in one fashion or another for about 18 years.  I can 
program in C, C++, and a bunch of languages I won't admit to :-) .  I am also
familiar with YACC, LEX, AWK, and all those other funny sounding animals.

Pete

- ------------------------------

Date: Tue, 31 Oct 89 12:32:51 EST
From: 45252-Peter L. Berghold <hplabs!allegra!violin!plb@gatech.edu>
Subject: Background Info
To: allegra!pyr.gatech.edu!morrison  (Traveller Programmer's Sig)

>> All of this hierarchical universe-building sounds an awful lot like the
>> Universe Simulation Mailing List (usml-request@hc.dspo.gov).  For those
>> of you with internet access, try ftp'ing to hc.dspo.gov (192.12.184.4)
>> to check out the usml archives there.
>> 
OK so I did.   I boy am I glad!   Hey Gang!  There is gold in them 
thar' hills!

I have in my possesion now a copy of a document written by a "Stan Shebs" 
that outlines some salient points that we should consider.   I took the 
time to convert this document from whatever-in-the-sam-hill format it was 
in into [ent]roff format.  The title of this document is "Simulating the 
Universe" and when formatted on my machine turned out to be 11 pages long.
It makes good reading.   

If anybody is interested in getting a copy of my "hacked" version, give 
me a good UUCP path and I will send it to you.

Other goodies I got from there include a program that uses rules rather 
different than Traveller's rules to generate star systems.   Some of its 
feature sets might be useable for this project tho'.  Planetary resources 
are figured out, as well as surface temps, seasonal effects from axial 
tilt, and a lot of other details.

I haven't finished evaluating all of the goodies that I glommed from 
there, but I think that these should not be overlooked.

Pete

- ------------------------------

Date: Fri, 20 Oct 89 10:59:13 EDT
From: dan@engrg.uwo.ca
Subject: Black Holes
To: traveller@dadla.wr.tek.com

In response to metlay:

Oops...Yes I had forgotten about the light-bending properties of blackholes,
and with a spaceship that can move over a wide area, it is quite probable
that they would be detected fairly easily.

> ... The problem with the
> current star system generation tables is that if they reflected the true
> population distribution of stars in the primary galactic medium, they'd 
> bore the average gamer to tears, because on a 3D6 table you'd need to roll
> a 3 or an 18 to get anything other than a red dwarf ... it's unreasonable
> to ask Traveller for a "more realistic" star system population 
> distribution

Yes I agree, however I was not discussing changing the star generation
process (which I would have left on the star generation list), rather coming
up with a reason for the generation as listed. I did want a sub table to
generate other stellar phenomanon used perhaps once or twice per sector.
The rules (scouts) even mention adding supergiants in at a very low density
(1 per sector or so).

My main points are/were:
1) Stars not represented correctly (2D, too many non-dwarf, no black holes.)
a) Assume all stars are projected into a plane. to get 2D board
b) a large number of stars are not mapped (usualy dwarfs) because of no
bodies in the system for bases/fuel.
c) Resultant stars provide density and composition we get from the star
generation tables. (I have a good reason for 2D as well which I haven't
brought up).
d) Add in other interesting stellar objects at a rate of a few per sector
(I like a lot of black holes myself...but see first paragraph).
e) this results in no changes to the maps (execpt where you want to mark
other stellar objects), nor to any rules, it is just a method of
perceiving the traveller universe so that it approximates ours more closely
(after all we have already assumed a 2D universe)

2) Obervation techniques don't seem to match today's standards.
a) Correct me if I'm wrong as I havn't dug up my Zhodani alien module, but
I believe that in the core exploration rules, you only get to see an
area 2-3 parsecs ahead of you. 
b) if you subscribe to (1) above, identifying good stars may that difficult.
c) if not, (I was probably exaggerating when I said we could see the entire
imperium from one location.) but even the near star map at 50 ly radius
represents a circle with a 30 parsec diameter, which is approximately a
sector (24x40 parsecs). That is with tech 8 ground based telescopes, a 
good TL 15 scout in space with no light noise sould get at least 4 sectors. 
(double range) 
d) additionaly as an jump-capable observer can more easily calulate 
positions by virtue of being able to observe from different points (from 
Leonard)

	-Dan
	

- ------------------------------

Date: Wed, 15 Nov 89 09:09:00 EST
From: morrison@pyr.gatech.edu (William B. Morrison)
Subject: Compilers
To: METLAY@vms.cis.pitt.edu, burdick@hpindl1.hp.com, dan@engrg.uwo.ca,

The survey results aren't in yet, but I can bet you almost
anything (almost ;-) that we will be using a "standard" C
compiler rather than C++ -- and that's looking at it from an
availability aspect (eg. I don't have one).

As a side note, does anyone have any problems trying to write
to the ANSI standard of C? Just trying to be upwardly
compatible...

- --Bill

- ------------------------------

Date: Wed, 15 Nov 89 10:32:57 EST
From: Dan Corrin <dan@engrg.uwo.ca>
Subject: Compilers
To: METLAY@vms.cis.pitt.edu, burdick@hpindl1.hp.com, dan@engrg.uwo.ca,

on  Wed, 15 Nov 89 09  morrison@pyr.gatech.edu (William B. Morrison) said:
> The survey results aren't in yet, but I can bet you almost
> anything (almost ;-) that we will be using a "standard" C
> compiler rather than C++ -- and that's looking at it from an
> availability aspect (eg. I don't have one).
>
Well I've spent two hours so far, and I am half-way done...
It should be ready by Friday, due to popular demand I waited until
2/3 were in, and I didn't get anything done on the weekend.
>
> As a side note, does anyone have any problems trying to write
> to the ANSI standard of C? Just trying to be upwardly
> compatible...
> 

ANSI C: Pascal for the 90's.
(Actually I heard that from one of my collegues here...:-)
I don't know the ANSI C standards, and if we use them, it will have
to be made available to everyone.
	-Dan

- ------------------------------

Date: Thu, 19 Oct 89 11:21:42 EDT
From: 45252-Peter L. Berghold <hplabs!allegra!violin!violin!plb@gatech.edu>
Subject: Discussion group membership and programming workload
To: allegra!pyr.gatech.edu!morrison (Traveller Programmer's Sig)

>> Currently, the discussion group has a membership of 12 people,
>> not all of whom are Computer Science/programmer types (not at      
>> least from what I understand). First we need to determine how       
>> many people in the group have programming skills (software
>> engineering, structured design, etc) -- just to get things
>> going. Then we can approach this in several ways:

One rabid C programmer here!  :-)    Let's start writing some code! 

>>    1) Pick one of the programmers as lead (perhaps a co-lead also),
	[stuff deleted]
>> 
I think one person should write the high level programming spec, filter it 
down to other folks that spec out individual module SETS and then the 
programmer types can have a field day from there.

Pete

- ------------------------------

Date: Fri, 3 Nov 89 16:24:56 EST
From: Dan Corrin <dan@engrg.uwo.ca>
Subject: Here it is...
To: morrison@engrg.uwo.ca

Just a few minor changes (and adding relion question, I find that
some people are touchy about religion in games).
Is there a reason why the industrialization index was not carried over? It
doesn't really matter, as I think it is a bit to picky of a detail. However
I just thought of another statistic that our governemnts use: %urban pop.
This can actually be calculated from the city generation sequence in
WBH, but might me interesting as a quick statistic.
(There are also other fun statistics that are used today such as infant
mortality, literacy rate, etc. These, though are kinda much.).

I will let you send it out, I will compare the answers and post the results
to the list (generation). If we get any new members, perhaps you could send
the questionaire out as part of the introductory message.

Do you know that a range of 1-10, being even has no middle or "average" 
answer? (which is one reason why I chose -5 to 5, which has problems too).

The time in the where to respond is flexible, but if not given, the results
may not arrive quickly enough. When should the posting to the list be made
(in order to get the late people). I will forward a copy of all the
filled out questionaires to you.

		-Dan

P.S. You did an excellent job of converting simple statements to nice
understanable sentances.

- ----- Begin Included Message -----

This questionaire may reflect the biasess of the writers, feel free to
enter your own comments.

   Please fill out all parts of the questionaire, and return to:
   		dan@engrg.uwo.ca
   by Friday November 10th. The results will be compiled, and posted back 
   to the list. If you feel you don't quite understand a question, answer 
   it anyway, and add a comment clairifying what you understand that the 
   question is asking. Remember that comments suggestions, and additions 
   are welcome.


GENERAL INFORMATION
- -------------------

Name:__________________________     E-Mail address:________________________

What machine(s) and OS(s) are available to you?:


Do you hace access to a PostScript printer?

Do you have a C compiler? If yes, specify:______________________

A C++ compiler? If yes, specify:________________________________

Years and type of C Programming Experience:

Do you have experience writing code to generate PostScript?

Do you wish to contribute as a programmer, tester, or as technical
consultant?

If you would like to program, would you be interested in being lead
or co-lead programmer (you would be responsible for coming up with
the preliminary design)?

Do you think we should use a co-ordinated programming effort using
software engineering techniques, or should we proceed in an ad hoc
manner with everyone contributing as they have time?

Do you possess knowledge in the following areas, and to what degree?

Astronomy/Astrophysics        -
Geology                       -
Archeology                    -
History/Political Science     -
Demographics                  -
Biology                       -
Fractals/graphics generation  -

Are there any other general areas of knowledge that you have that you
feel should be considered in generating star/planetary systems (at any 
level of detail) for Traveller/MegaTraveller?


General Implementation Considerations
- -------------------------------------

  System Considerations - This is to provide a general direction for deisgn.
  ---------------------
  If Build 1 is one program that generates strict Traveller/MegaTraveller
  systems, what do you envision Build 2 as being (eg. more functions
  to build 1, a planetary information generator taking input from
  the build 1 program, a trade/X-boat route generator taking input
  from build 1, etc)?

  How should we represent the (as yet unkown) data types?
  [Binary/Record | ASCII] [Single File | Multiple Files]

  Should our production system be one program or a series of programs?
  If a series of programs, how should we break them up (physical, political,
  scale [sector, subsector, system, planet], other)?

  What co-ordinate system should we use for sector numbering?
  [Reference|Galaxy Centre|Other]

  Should we include some data items used by other gaming systems
  (E.g. Galactic Conquest, Exploting Space, Other Suns, and Space Opera)?
  
  Should we include religion generation (for example from the world builders 
  handbook), as this may be offensive to some?


  Capabilities Considerations
  ---------------------------
  The following is a list of capabilities that may eventually be included
  in the final build of our system. On a scale of 1 to 10 (1=soon,
  10=later), please indicate at what stage a certain feature should
  be included into our system. A "1" generally means 'to be included in
  build 1, and a "10" means 'to be included in the last build before
  production - if at all'. Remember to add your own write-ins.

   Map Types                
   ---------               
   Empire maps               :
   Sector maps               :
   Subsector maps            :
   Solar System maps         :
   Planetary maps            :
   Regional (planetary) maps :
   City maps                 :
   Display in '3-D'          :
                                
   Info to be displayed on maps
   ----------------------------
   Number of planets in system :
   Planet Types/Symbols        :
      (exotic atmos, planet interdicted, stellar type, etc)
   Black Holes                 :
   Neutron Stars               :
   Brown Dwarfs                :
   Other stellar phenomenon    :

   Trade routes             :
   X-Boat routes            :
   Jump lanes               :
   Military/Scout Bases     :
   Government Type          :
   Law level                :
   Tech level               :
   Imperial Sancuaries, etc :

   Library Information
   -------------------
   Number of different *native* lifeforms : 
   Xenophobic reaction of population      :
   Major industries                       :
   Major Corporations                     :
   Exports                                :
   Imports                                :
   Trade duties and taxes                 :
   Restricted goods                       :
   Population density                     :
      (just because it's planet size A and
       population 4 doesn't mean it's not
       crowded).

  Government/Population Information
  ---------------------------------
  Bureaucracy level     :     (how much the government likes to hassle you)
  Loyalty of population :     (to government)
  Crime rate            :
  Punishment level      :     (do they execute you? for jay-walking?)
  Military Status       :     (at war, pacifistic, etc)
  Repression Index      :     (censorship, unjustified arrests, etc)
  Corruption Index      :     (corruption of government)
  Government Stability  :     (is the same government likely to be in
                                power as when we first arrived)
  Average Income        :
  Current Political/Important Persons:

  Other Information
  -----------------
  Background radiation level : 
  Meteor Infall              :


First Build Considerations
- --------------------------

These are general items/capabilities that we may want to consider for the
first (primitive) build of our generation system. Please feel free to add
items at your descretion. If you feel an item should be left for a later
build, please indicate with "LATER". Also, feel free to elaborate on any
item you believe needs more attention.

   System Considerations
   ----------------------------
   Should the first build be one program generating strict (only
   information currently in Traveller/MT/World Builder) systems (This
   would be the frame around which everything else is built)?

   Should we generate our system from scratch or should we use the
   "real" system generator or James Perkins' system generator as a
   *framework* around which to build our system (This means re-writing
   some of the code in those systems to conform to our deign)?

   If we use either of these systems, should their capabilities by
   included in build 1 or in subsequent builds?

   Should the first build be one program unto itself, or should we
   begin with our 'series of program' from the start?
   
   How much control over the random generation do we want the user to
   have (UPP(system) level, stellar level, planet level, or more)?


   Compatibility Considerations
   ----------------------------
   Please indicate if you feel that we should seperate output for each
   "compatibility level", exclusively target one system, or whatever.

   Traveller Compatible:
   MegaTraveller Compatible:
   World Builders Handbook Compatible:
   Other generation system(s):

- ----- End Included Message -----

- ------------------------------

Date: Mon, 23 Oct 89 13:41 EDT
From: (null)
Subject: Here we go.,..
To: morrison%pyr@gatech.edu

    As to the version of Traveller I play, I own MegaTraveller, but have
    played clasical and Mega.  Right now, I'm mainly interested in
    MegaTraveller, and have a friend who also plays, but has no net access
    at this point.  I haven't been very active due to other games I am
    concentrating on, but I am interested.

    I think we should go for at least sector and subsector maps probably
    solarsystem and planetary info.  As to planetary maps and city maps, it
    is something that should be open to talk, but not a main thrust.  It
    would take up too much time.  I cannot really comment on any more,
    because I haven't really done much in Traveller, nor have I had a
    chance to look at the programs.  LaTeR.

    							Gary Schreiber

- ------------------------------

Date: Mon Nov 13 16:12:47 1989
From: richard@agora.hf.intel.com (Richard Johnson)
Subject: Information to make available (maybe in maps)
To: morrison@agora.hf.intel.com

I'm mailing a copy of this to both dan@engrg.uwo.com and
morrison@pyr.gatech.edu, so you'll both know what's happening.

After filling out the questionaire Friday, I went out to
my favorite spot, the airport (I'm a student pilot).  While
there, I picked up a little (it really is little, but thick)
book, called the "Flight Guide".

This book is organized by states (U.S. states), and for each
state it contains a sketch of *every* airport (well every one
anyone but a crazy bush pilot would want to land at) and information
about that airport.

The information includes: distance and direction to town, length of
runway(s), width of runway(s), type of surface, fuel available, 
services, latitude, longitude, field elevation, known non-obvious
hazards, a telephone number to call, and so forth.

It occured to me that this type of book would be essential to any
shuttle or starship pilot.  

Do we want to consider something along these lines?  If so, I can provide
more information.  (I don't limit the concept to just starports,
I envision the concept could apply equally well to a larger-scale
concept like a subsector - less detailed).

Thanks for listening.
Richard Johnson
richard@agora.hf.intel.com

- ------------------------------

Date: Fri, 20 Oct 89 9:31:38 EDT
From: 45252-Peter L. Berghold <hplabs!allegra!violin!plb@gatech.edu>
Subject: More ideas.
To: allegra!pyr.gatech.edu!morrison  (Traveller Programmer's Sig)

Just a thought here:

The two programs that I have already for star system generation give their 
output in the form of either strictly ASCII flat files or POSTSCRIPT files.
Another option we might want to consider would be [txe]roff files.  Hex 
maps could easily be generated by PIC formatter input files, and as well you 
would be able to merge the textual information about a subsector with the 
graphics.   I have already been experimenting along those lines very 
successfully, and it wouldn't be too hard to do.

Pete

- ------------------------------

Date: Wed, 1 Nov 89 11:10:06 PST
From: Scott Ellsworth <sellswor@jarthur.claremont.edu>
Subject: Planet generators
To: morrison%pyr@gatech.edu

feel free to repost.  I would have sent it to the list, but I lost the 
address.  (Actually, I lost the machine that had the address on it... 
long story.) I would also be very inyterested in joining the star system 
generation group.  It is one of my two vices in traveller.  The other is 
automated ship generation programs that do deck plans.  That one I have 
not yet figured out a good way to deal with, but I will hack away till 
eventually...

  Scott
  Sellsworth@hmcvax
  sellswor@jarthur.claremont.edu

- ------------------------------

Date: Tue, 31 Oct 89 1:50:31 PST
From: Scott Ellsworth <sellswor@jarthur.claremont.edu>
Subject: Planet generators
To: morrison@jarthur.claremont.edu

Hello.  I heard a rumor that we now have a reliable way to get to your host.
The excitement of it all...

First off, I have a few opinions on what a good generator system should do:
I think we should stick to the MT/WBH format whenever and wherever possible.
This would maximize the number of people who can use the final product.

  I would not mind a series of three programs:

Sector or Subsector level - shoudl produce output comparable to one of 
the MT sector maps.  If we can come up with an easy 3D fix, I certainly 
would not mind it, as long as it is reasonably easy to implement.  By 
this, I mean that I should be able to alter all of the relevant portions 
of the rules and explain them to my players in under ten minutes if they 
are familiar with MT.  I should also be able to use a standard MT map with 
a little pre-game re-ordering.

  A possible way to do this would be to assign tenth or fifth 
parsec height numbers and make them an optional pre or postfix part of the 
system hex number.  Example: hex 0203 is jump one away from hex 0204; hex 
010101 is one jump away from 110101.  If a tenth is unreasonable, then 
perhaps a half or whole hex.  Merely making the average distance stay the
same does not account for the fact that one has access to another dimension
and thus one may have more or fewer worlds that form a contigous trade route.
The beauty of the pre/postfix on the hex number is that it can be freely
ignored if needed.  I would expect that this program keeps track of worlds
by hex number, with or without extensions.

  This program should be able to work from information already generated if 
the need arises.  It might behoove us to type in a copy a significant chunk 
of the spinward marches just so we can insure that our program's output looks
like the reference standard.

  System level - Should be able to produce a World Builder's handbook type 
of description of any system needed.  It gives each world in a system a
number, perhaps by orbit number and sattelite number, while remembering
that overall system by the same hex number we just finished taliking about
above.  We should really get decent system maps with some kind of reasonable
(log ?) scale lurking about in them.  This too should be able to work 
from a upp or some other input data.

  Planetary level - I often need this one.  A combination of reality and the
world builder stuff would be nice here.  I never have enough maps of planets 
hand, so this would be very handy.  It should probably use the sector hex
number along with the system orbit and sattelite orbit number to keep track
of where everything is.  One should be able to feed in a upp for system
and planet and get a reasonable map out that takes into account all of the
data in its map.  This one needs some flags in it that allow the user
to ask for certain parameters to be altered, like tectonic activity,
desired trade paramters, population density (clumped or distributed), and
other such.

  This is what I find that I would use, and would very much like to have.

The generation programs should be able to print out any given piece of this
data (like a subsectors worth at any given moment) as needed.

  By the way, I work on Apple //gses and Macs for the most part, though I
test-copile everything on out Sequent to make sure it works before I go
through the aches and pains of porting all of this to my computers.
For example, while the gensys programs have worked, the program that was to 
generate realistic planets has not yet our system, mostly because the links
to our site clipped everything faithfully at 80 characters.

  Background:
BS physics, working on a Masters in Applied Math.  Prgrammed in basic for
8 years, Pascal for 6, C for 1.  I have worked VMS, Unix, Macs and GSes.
I tend to be very good at finding bugs, not nearly as good at fixing them.
If you all are working on a project, I will be happy to give an opinon as a
dedicated rules fiend, but I don't know how much time I can devote to 
programming yet.

  Scott Ellsworth
  sellswor@jarthur.claremont.edu
  SELLSWORTH@HMCVAX

- ------------------------------

Date: Wed, 8 Nov 89 15:56:22 GMT
From: jaymin@maths.tcd.ie
Subject: Representation of Spheres
To: traveller@dadla.wr.tek.com

    Most of you seem to be discussing things over my head. Literially.
I am not so much concerned with generating huge number of stars but things
of planet sized and lower.
    The reccomended grid for worlds looks something like this:

               /\    /\    /\    /\    /\
              /  \  /  \  /  \  /  \  /  \      I.e. a 20 sided dice.
             /____\/____\/____\/____\/____\
            /\    /\    /\    /\    /\    /
           /  \  /  \  /  \  /  \  /  \  /
          /____\/____\/____\/____\/____\/
          \    /\    /\    /\    /\    /
           \  /  \  /  \  /  \  /  \  /
            \/    \/    \/    \/    \/

    You put hexes down the sides (one for each size of the world gives
you a constant scale) and pentegrams on the corners. This is really peachy
and plesant but has several drawbacks if you want to try to implement this
on a computer (If you don't trust me, I leave it as an exercise).
    Firstly I will outline what is needed for a computer representation:
    1) There must be a simple way to thread the sphere. I.e. we must easialy
be able to visit every point once and only once.
    2) We must be able to find all represented points withing a certain
radius of our subject point. E.g. I need all nodes within two of this one.
    3) We must be able to trace a diameter in a small number of cardinal
directions eventually reaching our starting point.
    4) It must be recursively definable. I.e. we must be able to increase
the resolution infinately.

    So what do we do?
    Hexes are nice, traditional and great for flat surfaces but a bit of a
bollox when you hit the corners. I think triangles are out best bet. Lets
work through the criteria in reverse order.
    (4) Recursively definable:
       /\               /\               /\
      /  \             /  \             /8_\
     /    \           / 2  \           /\2 /\
    /      \   ==>   /______\    ==>  /9_\/10\  ==> ...
   /        \       /\      /\       /\7 /\6 /\
  /    1     \     /  \ 1  /  \     /11\/1_\/14\
 /            \   / 3  \  / 4  \   /\3 /\5 /\4 /\
/______________\ /______\/______\ /12\/13\/15\/16\    no problem.
    (3) diameter.
    Always stand in a triangle with our backs to a base. If we go through
the left face, then with our back to that in the new triange go through the
right face repeatedly we will circumnavagate the sphere. Choosing which
base and wether to go left or right first gives us six directions.
    (2) find all points within a radius
    If you assume that an adjacent triangle is a triangle sharing
a base you have no problem and minimal difficulty on corners. A more
attractive way is to have any triangle which shares a vertex be one
unit away. This has rather more difficulties.
    (1) threading the sphere.
    I haven't been able to come up with an algorithmical way to do this.
It is, of course, trivial if one numerically orders the triangles. This
brings us to my mental block. To come up with a numbering system for
the triangles of the sphere that caters for the conditions above.
    What this boils down to is that the above scheme is mathematically
elegant it needs four things to make it usefull. (4) a way of uniquely 
identifying {preferably with an integer, or ordered pair} each triangle
element on the sphere. This numbering system must remain compatible as
the resolution is increased. (3) A function that when given a location
id and a direction, returns a location id of the next triangle along 
that diameter. (2) A function that is passed a location and returns
a fixed number of locations distance one from the given location. (1)
A function that given a locations returns another location such that
if continually called with the return value it will cycle through all
locations before returning.
    Is there a fresh mind out there that can see what I can't?

    			-- Jo Jaquinta

- ------------------------------

Date: 30 Oct 89 09:30:13 PST (Mon)
From: James T Perkins <jamesp@dadla.wr.tek.com>
Subject: Star Systems
To: joshua@atherton.com, jamesp@dadla.wr.tek.com,

Here's something that Mark Gellis requested be shared with the working
group here.  And Mark, if you'd like to join the discussion group, rather
than getting the periodic digest, you may write to:

	morrison@pyr.gatech.edu (Bill Morrison).

Traveller Mailing List Administrator	  James T. Perkins @ Tektronix, Inc
traveller-request@dadla.wr.tek.com	  Beaverton, Oregon, USA
uunet!dadla.wr.tek.com!traveller-request  "Load Auto/Evade, Beowulf!"

- ------- Forwarded Message

Date: Sat, 28 Oct 89 13:16:51 -0500
From: Mark Gellis <f3w@mentor.cc.purdue.edu>
To: traveller-request%dadla.wr.tek.com@RELAY.CS.NET
Subject: Star systems

James, if this meets your approval, please pass it on to the rest of the 
group.

Phew!  I just read (skimmed) the discussion on mapping.  A few comments and
suggestions that may be of some help...

3D mapping is easy if you add a calculation subroutine to determine 
distances between stars of different "z" levels.  In fact, both 2D and 3D 
maps might be better if there was a table (like in modern road atlases) 
that show how far in jumps or hyperdrive days or whatever different people 
use different stars are from each other.  Equally easy would be adding a 
star type generator that would not only determine the location, but the 
main sequence stellar type (using percentages...01-73: M; 74-88: K; 89-95: 
G; 96-98: F, 99: A; 00: other (black hole, supergiant, whatever your little
heart desires)--actually A-type stars make up only about .6% of the main 
sequence, and white dwarves make up about 5% of all stars, but people can 
modify the system as they please.)

By the way, for realism fans who are afraid M-type stars offer nothing for
gamers...GOOD NEWS.  Remember, M-type stars are just as likely to have
planets as G-type stars, and even if most of them are Neptune-like gas 
giants, big deal?  Remember our discussion of space habitats, each one a
floating city with a million people, clustered in nations of a billion 
people or more.  Gas giants have giant moons for raw materials (okay, okay,
I know a lot of it will be water ice, think of it as "panning for gold" on
a big scale) and lots of hydrogen to fuel fusion power plants.  And 
asteroid belts have high quality raw materials in great abundance and 
easy access.  The average solar system can have several hundred "worlds,"
each one consisting of a network of a hundreds of space cities--tens or
hundreds of billions of NPCs who need the help (or are asking to get killed
by) your player characters!

(By the way "a hundreds of" should read "hundreds of"--I apologize for being
such a bad typist)

     Mark

- ------- End of Forwarded Message

- ------------------------------

Date: Tue Oct 31 13:54:17 1989
From: richard@agora.hf.intel.com (Richard Johnson)
Subject: traveller maps
To: morrison@agora.hf.intel.com

  	About copyrights (re: Canada and US) -- the laws are now basically
	the same.  The U.S. has finally changed its laws to comply with 
	the international standards for copyrights.  Whatever the conditions
	are, will be same in both countries.  

	In general, those who write portions of the program(s) have
	first right to those portions (unless somebody paid them to
	do it, and under specified conditions).  

	For our purposes, we specify that these materials are for 
	public use, freely distributed, or whatever we want.  We make
	sure our terms are clearly displayed by the user, and we make
	sure we enforce our terms.  This means the terms must be 
	visible in the compiled version, not just the source code.  It
	also means we can't ask for $$$ and controlled distribution
	unless we can *and do* go after people who violate our terms.

- ------------------------------

Date: Fri, 27 Oct 89 10:44:17 edt
From: mleymaster@lucy.wellesley.edu
Subject: TRAVELLER Star System Data Formats
To: morrison@relay.cs.net:mleymaster@lucy.wellesley.edu

Dear Bill; Jim Perkins suggested I contact you about my interest in a
simple yet compatible data format for TRAVELLER Sector files.  I know of
Marc Miller's format that was published in Challenge, and note that the
extensive data files from GDW/DGP uploaded to GENIE add a chunk of ASCII
in the front for the system names, wasting a batch of space because most
systems are unnamed.  Are you aware of any evolving formats that would save
me the embarassment of building an avoidably non-standard program?  I am 
working in the PC-XT environment with sequential ASCII records that are 
readable on a simple editor.  Are there any old messages that address this
subject that you might be willing to E-mail to me?  Thanks --Mark

- ------------------------------

Date: Wed, 1 Nov 89 09:55:19 est
From: mleymaster@lucy.wellesley.edu
Subject: Traveller Star System Generation Group
To: morrison@relay.cs.net:mleymaster@lucy.wellesley.edu

Bill- I would love to join the discussion.  I vote strongly for ASCII, and
suggest excluding hi-eighth bit and non-printing characters. It is key that
any sophisticated work product be accessible to those with simple machines,
such as Commodore 64s and Apple IIs.  I think the databases are best if 
readable (and revisable) by hand with a simple editor, which argues strongly
for a sequential not random file that can function without indexes.  What 
those of us with more sophistication wish to do (build indexes, relational 
lists, graphic front ends etc) is fine, so long as the building blocks we
start with don't require any particular form of display, CPU or programming
language.  I'd be obliged if you let me know what you think. --Mark

- ------------------------------

Date: Wed, 8 Nov 89 08:34:59 EST
From: morrison@pyr.gatech.edu (William B. Morrison)
Subject: Where to send the surveys
To: METLAY@vms.cis.pitt.edu, burdick@hpindl1.hp.com, dan@engrg.uwo.ca,

Please remember to send the surveys to Dan Corrin <dan@engrg.uwo.ca>
and not to me. He will be collecting them and I will post the
results.

- --Bill

- ------------------------------

End of Traveller System Generation Group Digest
******************************

All opinions and material above is the responsibility of the originator.
Submissions: traveller@dadla.wr.tek.com, or uunet!dadla.wr.tek.com!traveller
Administrator: traveller-request@dadla.wr.tek.com (James Perkins)
The TML is made possible by facilities provided by Tektronix, Inc.

-------- End of TML Messages --------

